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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 



The present document specifies the functional architecture and information flows of the Voice Call Continuity feature 
which provides the capability to transfer the path of an existing voice call between a 3GPP CS system (GSM/UMTS) 
and IMS, and vice versa. These capabilities were designed per requirements in TS 22.101 [20]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.228: "Service requirements for the Internet Protocol (IP) multimedia core network 
subsystem (IMS); Stage 1". 

[2] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[3] 3GPP TS 23.018: "Basic Call Handling; Technical realization". 

[4] 3GPP TS 23.078: "Customized AppHcations for Mobile network Enhanced Logic (CAMEL) 

Phase 4; Stage 2". 

[5] 3GPP TS 33.102: "3G security; Security architecture". 

[6] 3GPP TS 33.203: "Access security for IP-based services". 

[7] 3GPP TS 22.952: "Priority service guide". 

[8] 3GPP TS 22.004: "General on supplementary services". 

[9] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services; Stage 1". 

[10] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2". 

[II] 3GPP TS 23.002: "Network Architecture". 

[12] 3GPP TS 23.01 1 : "Technical realization of Supplementary Services". 

[13] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions". 

[14] 3GPP TS 24.010: "Mobile Radio Interface Layer 3 - Supplementary Services Specification - 

General Aspects". 

[15] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[16] ITU-T Recommendation E.164: "The international public telecommunication numbering plan". 

[17] 3GPP TS 23.226: "Global Text Telephony". 

[18] RFC 3261 (June 2002): "SIP: Session Initiation Protocol". 

[19] OMA-ERELD-DM-V1_2-20060602-C: "Enabler Release Definition for OMA Device 

Management, Candidate Version 1.2". 
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[20] 3GPP TS 22.101: "Service aspects; Service principles". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [15] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [15]. 

Anchoring in IMS: Insertion of the Domain Transfer Function in the signalling path of the voice call/session 
establishment in order to enable the capability of domain transfer for this call/session. 

IP Multimedia Routing Number (IMRN): An IMRN is a routable number that points to the IM CN subsystem. In a 
roaming scenario, the IMRN has the same structure as an international ISDN number. The Tel URI format of the IMRN 
is treated as a PSI within the IM CN subsystem. 

CS Domain Routing Number (CSRN): A CSRN is a number that is used to route a call from the IM CN subsystem to 
the user in the CS domain. 

Domain Transfer: Transfer of the access leg of a voice call on a UE from CS domain to IMS and vice versa while 
maintaining active session. 

Access Leg: This is the call control leg between the VCC UE and the DTE. 

Remote Leg: This is the call control leg between the DTE and the remote party from the VCC subscriber's perspective. 

VCC UE: User Equipment supporting the VCC feature. The VCC UE is defined in clause 5.3.2 of this document. 

VCC Domain Transfer Number (VDN): A public telecommunication number, as defined by ITU-T Recommendation 
E.164 [16] used by the UE to request the DTE to perform Domain Transfer to the CS domain from the IMS. 

VCC Domain Transfer URI (VDI): A SIP URI used by the UE to request the DTE to perform Domain Transfer to the 
IMS from the CS domain. 

3.2 Abbreviations 

Eor the purposes of the present document, the abbreviations given in TR 21.905 [15] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [15]. 

Spec Third party call control 

CSAE CS Adaptation Function 

CSRN CS Domain Routing Number 

DSF Domain Selection Function 

DTE Domain Transfer Function 

iFC Initial Filter Criteria 

IMRN IP Multimedia Routing Number 

PSI PubHc Service Identity 

VCC Voice Call Continuity 

VDI VCC Domain Transfer URI 

VDN VCC Domain Transfer Number 
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VCC Concepts 



4.1 General 

Voice Call Continuity is a home IMS application that provides capabilities to transfer voice calls between the CS 
domain and the IMS. VCC provides functions for voice call originations, voice call terminations and for Domain 
Transfers between the CS domain and the IMS and vice versa. 

The VCC application is implemented in the user's home network. Voice calls from and to a VCC UE are anchored at 
the VCC application in the home IMS to provide voice continuity for the user during transition between the CS domain 
and the IMS. VCC voice calls in either the CS domain or IMS are anchored at the VCC application in the home IMS 
using standard CS domain techniques available for rerouting calls at call establishment. A Spec (Third party call 
control) function is employed at the VCC application to facilitate inter domain mobility through the use of Domain 
Transfers between the CS domain and the IMS. Domain Transfers may be enabled in one direction (i.e. from the CS 
domain to the IMS or from the IMS to CS domain), or in both directions as per network configuration requirements. 
The VCC application has the capability to perform domain transfers for a VCC UE's voice session multiple times in 
both directions. 

The capability of anchoring in IMS of Emergency calls and CS calls other than voice calls (e.g. CS Video, CS Data, CS 
Fax, SCUDIF calls...) is not specified in this document. Anchoring in IMS of voice calls/sessions originating from or 
terminating to a subscriber that does not have a VCC UE or an active VCC subscription is subject to operator policy. 
CS originating and terminating calls that are not anchored are handled according to the normal CS call originating & 
terminating procedures. Similarly, IMS originating and terminating sessions that are not anchored are handled 
according to the normal IMS session originating and terminating procedures. 

4.2 Radio environments 

Since simultaneous transmit and receive of 2G CS and 3G PS radio is not supported in current 3GPP specifications. 
Domain transfer of a voice call between the 2G CS domain and IMS accessed via a 3G PS domain IP-CAN is out of 
scope of this specification. 

4.3 Domain selection 

The domain selection function shall be able to use the following to determine which domain shall be selected to 
terminate the voice call: 

- The state of the UE in the circuit switched domain. This state information shall include: Detached, Attached. 

- The UE capability to support the full duplex speech component of IMS multimedia telephony. 

- The state of the UE in the IMS. The state information shall include: Registered, Unregistered. 
The last known access network type of the IP-CAN when the UE is IMS registered. 

- User preferences and/or operator policy. 

- The domain used by an existing call anchored at the VCC application. 

The media components included in an incoming IMS multimedia telephony session. 

NOTE: Domain selection is not aware that the VCC UE has changed the access network due to cell reselection 
when the UE is in idle mode. Termination selection based on the last known access network type in this 
case may not be correct. 

In the case where call delivery attempt fails in the selected domain and where the operator policy requires it, the domain 
selection function in the VCC application may re-attempt the call setup to the other domain. The re-attempt shall be 
performed only once, to avoid call looping. 

Failure of a call delivery attempt is considered for the present clause to be any call delivery attempt that does not result 
in successful establishment. This may include: 
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- The UE did not respond to the call establishment request. 

- - For service compatibility reason (e.g. Text telephony, TS 23.226 [17]), the UE may reject the IMS 
terminating voice attempt with a cause code to indicate reestablishment via the CS domain. The domain selection 
function shall re-attempt the call setup using the CS domain. 

NOTE: Call forwarding in the CS domain invoked as part of a call delivery attempt is not considered an attempt 
failure. 

4.4 Anchoring in IMS of VCC subscriber calls 

4.4.1 Calls originated by VCC subscribers 

Anchoring of IMS multimedia telephony sessions are controlled by the operator policy. The default policy is all IMS 
multimedia telephony sessions originated by VCC subscribers in the IMS are anchored in the IMS in order to facilitate 
domain transfer of the voice component to the CS domain. 

Voice calls originated by VCC subscribers in the CS domain may or may not be anchored in the IMS, subject to 
operator policy. A CS originated call has to be anchored in IMS to allow domain transfer to occur. 

Voice calls which IMS cannot route are not anchored in IMS. Considering a voice call originated by a roaming VCC 
subscriber, using a called party number not in the international format and for which the home IMS network has no 
means to translate (e.g. a local number), IMS has no way to determine the intended local destination and cannot anchor 
the call. CAMEL processing in the CS domain may solve this problem by translating dialled numbers into the 
international number format according the following guidelines: 

- If the VCC UE is in the HPLMN, no translation is required, the call is anchored. 

If the VCC UE is not in the HPLMN but located in a VPLMN with known translation rules for that number, 
translation is performed and the call is anchored. 

- If the VCC UE is not in the HPLMN but located in a VPLMN with no known translation rules for that number, 
no translation is performed and the call is not anchored. 

If a call from a VCC subscriber is not anchored in the IMS, domain transfer is not supported for that call. 

Priority call handling is not preserved if a priority call, originated by VCC subscribers in the CS domain, is anchored in 
IMS. 

NOTE: See TR 22.952 [7] for information on priority subscriber and priority call handling. 

4.4.2 Calls terminated to VCC subscribers 

Anchoring of IMS multimedia telephony sessions are controlled by the operator policy. The default policy is that all 
IMS multimedia telephony sessions to VCC subscribers directed to the IMS are anchored in the IMS in order to 
facilitate domain transfer of the voice component to the CS domain. 

Voice calls to VCC subscribers directed to the CS domain which are terminated in the CS domain may be rerouted to 
the IMS to facilitate domain transfer of the call, subject to operator policy. If a call to a VCC subscriber is not anchored 
in the IMS, domain transfer is not supported for that call. 



4.5 Domain transfer procedures 



When a VCC UE is active in a voice session, voice continuity between CS domain and IMS is enabled by execution of 
the Domain Transfer procedures. Handling of any non- voice components in the IMS multimedia telephony session(s) 
after the domain transfer of voice component is out of the scope for this specification. 

VCC UE calls are anchored at the VCC application in the home IMS upon session establishment to enable a 3rd party 
call control (Spec) function for control of the Domain Transfer procedures executed during the call. All initial and 
subsequent Domain Transfers associated with a VCC session(s) are initiated by the VCC UE and executed and 
controlled by the VCC application in the home IMS. 
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Simultaneous registration in both domains is required for the initiation of the Domain Transfer procedure. When the 
VCC UE determines that Domain Transfer is desirable and possible, a registration is performed by the VCC UE in the 
transferring-in domain if the user is not already registered). A new call context is established by the VCC UE toward the 
VCC application in the home IMS. Signalling and bearer resources are allocated in the transferring-in domain and the 
user's active session is transferred from the transferring-out domain. The VCC application in the home IMS executes 
Domain Transfer. Resources in the transferring-out domain are subsequently released. 

The VCC application in the home IMS generates charging information for all Domain Transfers for VCC subscriber 
voice session for the purpose of billing and charging. 

The following requirements are applicable to Domain Transfers in CS to IMS and IMS to CS directions: 

- Initiation of the CS to IMS Domain Transfer procedures for an ongoing voice call may be based on radio 
condition. 

- Initiation of the IMS to CS Domain Transfer procedure for an ongoing voice call may be based on radio 
condition and IP connectivity to IMS. 

- It shall be possible to support Domain Transfer for a roaming user. 

- The perceived service disruption should be minimized from the end user's perspective. 

The Domain Transfer procedure latency should be minimized. 

Voice call quality should be maintained. The number of transcoding stages introduced by the architecture should 
be minimized. 

- Consistent charging information across domains shall be provided when Domain Transfer is performed. 



4.6 Regulatory aspects 



Support of IMS emergency calls is described in TS 23.167 [13]. The current IMS emergency call architecture does not 
allow for the execution of services for this type of call. Because domain transfer capability is included as a service 
loaded via the iFC, domain transfer of these calls is not possible. Also, emergency calls in the CS domain will not have 
origination triggers detected in the VMSC, thus calls will not be rerouted to the IMS for anchoring in IMS. 

Emergency calls will thus remain in the domain in which they were originated, regardless of changing conditions that 
might dictate domain transfer for normal calls. 

A UE engaged in an emergency call shall not request a domain transfer. 



5 Architecture 

5.1 General 

The VCC Architecture reuses many existing elements in both the CS domain and IMS. 

The overall model and impacts to the various elements is provided in the following paragraphs. 

5.2 Reference model 

Figure 5.1 depicts the VCC reference architecture. 
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Figure 5.1 : VCC Reference Architecture 
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5.3 VCC entities 
5.3.1 VCC application 

5.3.1.1 General 

The VCC application comprises a set of functions required for a VCC UE to establish voice calls and control the 
switching of the VCC UE's Access Leg between the CS domain and IMS whilst maintaining the active session. These 
functional entities are described in clause 5.3.1.2. 

Some of the entities used by the VCC application may have a general applicability outside the scope of VCC. 

NOTE 1 : Functional entities with an ISC interface may be implemented in one or more SIP Application Servers 
providing the functions described in this clause. 

NOTE 2: The grouping of functions into a particular clause does not necessarily represent an architectural 
requirement for implementation. 

NOTE 3: The use of MAP by the functional entities is an implementation option. 

5.3.1 .2 Functional Entities used by the VCC application 

5.3.1 .2.1 Domain Transfer Function (DTF) 

The Domain Transfer Function (DTF) uses the ISC reference point towards the S-CSCF for execution of the Domain 
Transfer functions. The DTF performs the following functions: 

- Executes the transfer of the VCC UE access between the CS domain and IMS as requested by the VCC UE. 

- Insertion of 3rd Party Call Control (3pcc) upon call establishment to enable transfers between the CS domain and 
IMS. 

- Maintains Domain Transfer Policies. 

Maintains information describing the current domain being used by the VCC user's active session for use in 
subsequent domain selection. 

- Provides Domain Transfer specific charging data. 

- Preserves the information necessary to deliver Calling Line Identity for VCC UE voice sessions anchored in 
IMS. 

Preserves the information necessary to deliver Connected Line Identity for VCC UE voice sessions anchored in 
IMS. 

Editor's note: In case user's Late Call Forwarding, Call Deflection or Explicit Communication Transfer 

Supplementary Services is invoked in the CS domain after anchoring in IMS, the DTF shall maintain the 
correct call state so that domain transfers for subsequent calls of the user are not rejected. It is for further 
study as to how the DTF maintains the correct call state. 

5.3.1 .2.2 Domain Selection Function (DSF) 

The Domain Selection Function provides selection of the domain to be used for delivery of a VCC UE's incoming call, 
as specified by operator policy or user preferences. Operator policy shall have precedence to user preferences. The DSF 
performs the following functions: 

- Determines IMS registration status to aid in domain selection. 

- Determines CS registration status to aid in domain selection. 

- Communicates with the DTF to retrieve current domain used for VCC UE active calls to use it in domain 
selection for incoming calls. 
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- Determines the CSRN. 

NOTE 1 : It is an implementation option as to how the DSF determines the CSRN. The DSF may collaborate with 
the CS AF for determination of the CSRN. 

NOTE 2: The location where the Domain Selection operator policy and user preferences are stored is not specified 
in this document. 

5.3.1 .2.3 CS Adaptation Function (CSAF) 

The CS Adaptation Function (CSAF) acts as the VCC UE's proxy into IMS for: CS originated calls and CS legs 
established for Domain Transfer to CS. 

The CSAF performs the following functions: 

- Identifies the VCC user to IMS for CS originations and CS legs established for Domain Transfer to CS. 

- Communicates call related data from CS domain to IMS; e.g. communication of original called party number for 
CS originations. 

- Allocate/deallocate IMRN for routing CS calls to IMS. 

- Is a SIP UA to IMS for CS calls on behalf of the VCC UE. 
CSAF uses the Ma towards the I-CSCF and the ISC towards the S-CSCF. 

NOTE 1 : The CSAF may collaborate with the CAMEL Service for interworking with CS domain as needed. 

NOTE 2: The interaction of CSAF and CAMEL Service is outside the scope of this specification, therefore the 
allocation entity (CSAF or CAMEL Service) of IMRN is an implementation decision. 

5.3.1.2.4 CAIVIEL Service 

The CAMEL service function operates either independently or in collaboration with the CSAF. It performs the 
following functions: 

- Enforces CS redirection policy. 

- Allocate IMRN for routing CS calls to IMS. 

- Communicates call related data from the CS domain to the IMS; e.g. communication of original called and 
calling party numbers for CS origination. 

- Reroutes the CS calls to the IMS using an IMRN. 

- Resolves the VCC Application Servers' PSI from the VDN upon Domain Transfer to CS. 

NOTE 1 : Use of the HSS by the gsmSCF to access the CAMEL Service is for further study. 

NOTE 2: The interaction of CSAF and CAMEL Service is outside the scope of this specification, therefore the 
allocation entity (CSAF or CAMEL Service) of IMRN is an implementation decision. 

5.3.2 VCC UE 

The VCC UE is a VCC capable User Equipment with an active VCC subscription. It supports voice over both IMS and 
CS domains. The VCC UE performs the following functions: - 

- Stores and applies domain selection policies for both originating calls and Domain Transfers. 

- Selects which domain to use for originating calls; it does so based on domain selection policies. 

- Communicates the user preferences in order to indicate which domain is preferred for terminating calls. 

- Applies the received VCC operator policy prior to process VCC call request (e.g. Call origination, Domain 
Transfer request). 
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- - Stores VDNA^DI for domain transfer execution. 

- Allows the stored VDNA^DI values to be updated. 

5.4 Reference points 

5.4.1 DTF - S-CSCF, CSAF - S-CSCF, DSF - S-CSCF reference point 
(ISC) 

The ISC reference point between Serving CSCF and the Application Servers is described in TS 23.002 [11]. 

5.4.2 CSAF - l-CSCF, DTF - l-CSCF reference point (Ma) 

This reference point may be used by the CSAF to route messages to the DTF function via the Ma reference point. The 
Ma reference point between Interrogating CSCF and the Application Servers is described in TS 23.002 [11]. 

5.4.3 Functional entity - HSS reference point 

This reference point is used by the functional entities (DTF, CSAF, DSF) to retrieve information from the HSS. This 
reference point includes Sh; Sh is found between the Application Servers and the HSS and is described in 
TS 23.002 [11]. 

5.4.4 gsmSCF - VMSC reference point 

This reference point is used by the gsmSCF to provide routing of CS origination calls and CS legs established for 
Domain Transfer to CS. This reference point uses the gsmSCF to gsmSSF interface as specified in TS 23.078 [4]. The 
information from the trigger messages are used on the unspecified interface to the CAMEL Service. 

5.4.5 gsmSCF - HSS reference point 

This interface is used by the gsmSCF to request information from the HLR. The reference point between the gsmSCF 
and the HSS is described in TS 23.078 [4]. 

5.4.6 VCC Application - VCC UE reference point (V3) 

V3 is a reference point between VCC UE and the VCC Application. 

This reference point may be realized by using Ut interface as described in TS 23.002 [11]. 

6 Information flows and procedures 

6.1 Registration 



6.1 .1 CS domain registration 



The VCC UE may register (attach) in the CS domain whenever there is CS coverage. The existing mobility 
management mechanisms are used in both the UE and the network. 
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6.1.2 IMS registration 

Whenever the VCC UE acquires IP connectivity via an IP-CAN, the UE may register in the IMS. Registration with IMS 
is in accordance with the procedure as defined in TS 23.228 [2]. The filter criteria shall contain a condition that a 3rd- 
party registration should be performed via the ISC interface. IMS registration is performed independently of the UE's 
CS state. 

1. The UE registers in the IMS as described in clause 5.2.2.3 of TS 23.228 [2]. 

2. The S-CSCF informs the DSF (Domain Selection Function) about the registration, using the procedures defined 
in clause 6.3 ofTS 23.218 [10]. 

6.2 Origination 
6.2.1 General 

VCC user initiated voice calls from a VCC UE (in the CS domain or IMS) are anchored with the functionality provided 
by the VCC Application in order to facilitate control of the bearer path upon domain transfer. 



6.2.2 VCC UE origination from CS domain 



6.2.2.1 



General 



The CS originating voice calls of a VCC UE are anchored at DTE, which behaves as a SIP- AS as described in 
TS 23.228 [2] to set up a 3pcc to control the bearer path of the call. The original called party number along with other 
information required to complete the call is made available to the VCC Application such that its functional elements can 
originate a call to the remote party on behalf of the VCC user using the third party call control function (TS 23.228 [2], 
section 4.2.4). 

Figure 6.4.1.2-1 in clause 6.4.1.2 illustrates 3pcc at the DTE when the Access Leg is established for CS voice sessions 
showing its use as precondition of Domain Transfer procedures. Figure 6.2.2.1-1 shows a possible optimization when 
anchoring CS originating sessions at the DTE. The figure shows the 3pcc at the DTE and its use for Domain Transfer 
procedures; hence it only shows the signalling and bearer components relevant to the precondition of Domain Transfers. 
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Figure 6.2.2.1-1 : Spec at DTF for CS Originations 
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6.2.2.2 



UE origination from CS domain using CAMEL 



VCC UE originated voice calls are re-routed using CAMEL to the user's home IMS network for anchoring in IMS. The 
UE establishes the call using standard call origination procedures; CAMEL origination triggers at the VMSC then 
invoke signalling towards the gsmSCF. The gsmSCF instructs the VMSC to route the call towards the IMS or to 
continue with normal call origination procedures. 

In order to determine the necessary information to complete the call, the CSAF uses: 

- either the IMRN; or 

- ISUP information (this includes calling party number, original called party number, redirection number and 
redirection information) which are mapped by the MGCF to SIP headers, if the network configuration can 
reliably convey the ISUP information. 

NOTE: In order to determine the necessary information to complete the call, an interaction between the CSAF 
and CAMEL Service could be required. This interaction is outside the scope of this specification. 

Figure 6.2.2.2-1 describes the initial session setup of Mobile Originated Call processing for a VCC user initiated call 
from CS domain CAMEL is used to redirect the call to IMS. Calls shall not be re-routed to the home IMS network if 
there is no means to translate the called party number (e.g. local number) into a routable format to the intended local 
destination. 
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Figure 6.2.2.2-1 : CS call origination from the VCC user 

1. The VCC user originates a voice call in the CS domain using a VCC UE to party-B. 

2. Origination triggers at the VMSC are detected; VMSC sends an Initial DP message towards the gsmSCF. 

3. The gsmSCF invokes the VCC Application's CAMEL Service which determines that the call needs to be 
rerouted to IMS for VCC; thus, the CAMEL Service reroutes the call to the IMS by returning an IMRN to the 
gsmSCF; otherwise it responds with a CAP Continue. 

NOTE: How the information available to the CAMEL Service is used to decide whether the call should be routed 
through the IMS is implementation specific and not standardized in this specification. The interface 
between the gsmSCF and the CAMEL Service is unspecified. 
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4. The gsmSCF responds with a CAP Connect message containing the Original Called party ID and Destination 
Routing Address. Destination Routing Address contains the IMRN to route the call to the CSAF. Handling of 
Destination Routing Address and Original Called party ID is as defined in TS 23.078 [4]. 

5. The VMSC routes the call towards the user's home IMS network using the IMRN via an MGCF in the home 
network. 

6. The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating VCC user. The calling 
party number and/or original called number are included in the INVITE if they are received from the PSTN call 
setup signalling (e.g., ISUP). 

7. The I-CSCF routes the INVITE based on one of the following standard procedures specified in "PSI based 
Application Server termination - direct and PSI based Application Server termination - indirect" procedures in 
TS 23.228 [2]. 

7a. The I-CSCF forwards the INVITE to the CSAF via the S-CSCF that is assigned to the IMRN. 

7b. The I-CSCF forwards the INVITE directly to the CSAF. 

8. If When the INVITE arrives at the VCC AppHcation, it is processed by the CSAF of the VCC AppHcation which 
may use the IMRN to retrieve the original called party number and the calling party number from the CAMEL 
Service. The CSAF uses the original called number and the calling party number to setup the outgoing call leg to 
party-B in accordance with the AS origination procedure defined in clause 5.6.5 of TS 23.228 [2] 

9. The DTE of the VCC Application anchors the originating session for enablement of domain transfers for the 
session as part of this procedure based on operator policy. 

Note: Steps 8 and 9 may comprise of a sequence of messages for communication to/from different VCC 
Functional Elements. 

10. The DTF sends the INVITE back to the S-CSCF for completion of the call toward the remote end. 

Standard originating call setup procedures as per TS 23.228 [2] are followed to continue the call setup at the S-CSCF 
for the VCC user. 

6.2.3 VCC UE origination from IMS domain 

Existing Mobile Origination procedures described in clauses 5.6.1 or 5.6.2 of TS 23.228 [2] are used to establish a 
session. Originating iFC for the VCC user results in routing of the IMS originating sessions to the DTF in the home 
IMS network, where the DTF uses 3rd party call control as per TS 23.228 [2] to initiate a call to the remote party on 
behalf of the user. 

Figure 6.4.1.2-1 shows 3pcc at the DTF when the Access Leg is established for IMS voice sessions to illustrate its use 
as precondition of Domain Transfer procedures. In order to avoid a situation where other SIP Application Servers that 
will be used for the duration of the session are released upon domain transfer, the DTF should be the first Application 
Server of any Application Servers that need to remain in the path of the call after domain transfer. 

6.3 Termination 
6.3.0 General 

Voice calls to VCC subscribers coming from the IMS or the CS domain may be anchored in the IMS according to the 
rules provided in clause 4.4.2 to facilitate domain transfer and may finally be delivered to the UE via the IMS or the CS 
domain based on the criteria as described in clause 4.3. 
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6.3.1 Terminated call coming from CS 

It is not mandated how to route the call toward the IMS in order to allow for different deployment scenarios, 
optimisations and operator requirements. Once the call is in the IMS, subsequent processing of the call is as described 
clause 6.3.2. 

NOTE: Annex A contains several call routing techniques, which may be used by current CS networks. 

6.3.2 Terminated call coming from IMS 

Existing Mobile Termination procedures described in TS 23.228 [2] clauses 5.7.1, 5.7.2, 5.7.2a are used to establish a 
session towards a VCC UE. The Service Logic invoked for the VCC subscriber results in routing of the IMS 
terminating sessions to the DTE, where it uses 3rd party call control as per TS 23.228 [2] to initiate a call to the remote 
party on behalf of the user. 

Eigure 6.4.1.2-1 shows 3pcc at the DTE when the Access Leg is established for IMS voice sessions to illustrate its use 
as precondition of Domain Transfer procedures. In order to avoid a situation where other SIP Application Servers that 
will be used for the duration of the session are released upon domain transfer, the DTE should be the last Application 
Server of any Application Servers that need to remain in the path of the call after domain transfer. 

6.3.3 Terminated call directed to CS 

Eigure 6.3.2-1 describes how the signalling path is established toward a VCC user when the user is roaming in the CS 
Domain and the call is directed to CS. 
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Figure 6.3.2-1 : Terminated call directed to CS domain 

1 . An INVITE arrives at the S-CSCF which includes a Request URI in Tel URI or SIP URI format. 
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2. The S-CSCF invokes the necessary service logic as appropriate. 

3. The S-CSCF forwards the initial INVITE to the VCC AppHcation over the ISC interface. 

4. The DTP of the VCC Application anchors the call depending on operator policy. 

5. The DSF of the VCC Application selects the CS domain for call routing based on the criteria as described in 
clause 4.3. 

6. The DSF of the VCC Application determines the CS domain Routing Number (CSRN), optionally in 
collaboration with the HSS and the CSAF. 

NOTE 1 : Steps 4 thru 6 may consist of a sequence of messages for communication to/from different VCC 
Functional Elements. 

NOTE 2: The invocation order of VCC Functional Elements is implementation specific. 

NOTE 3: Annex C describes several implementation options which may be used by current CS networks to prevent 
Circular Looping when determining the CSRN for CS Terminations. 

7. Multiple options are possible, two of which are shown: 

7a. The DSF sends an INVITE including the CS domain routing number as the Request URI toward the S-CSCF. 
The INVITE including the CSRN contains sufficient information to allow the S-CSCF to determine that the 
session is to be routed to the CS domain. 

7b. The DTE sends an INVITE including the CS domain routing number as the Request URI toward the S-CSCF. 
The INVITE including the CSRN contains sufficient information to allow the S-CSCF to determine that the 
session is to be routed to the CS domain. 

8. The S-CSCF routes the INVITE toward the CS domain per TS 23.228 [2]. 

6.3.4 Terminated call directed to IMS 

Figure 6.3.4-1 below describes how the signalling path is established toward a VCC user when the user is roaming in 
the IMS Domain and the call is directed to IMS. 
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Figure 6.3.4-1 : Terminated call directed to the IMS domain 

1 . An INVITE is sent to the S-CSCF including a Request URI in Tel URI or SIP URI format. 

2. The S-CSCF invokes necessary service logic as appropriate. 

3. The S-CSCF forwards the INVITE toward the VCC AppHcation over the ISC interface.. 

4. The DTE of the VCC Application anchors the call depending on operator policy. 

5. Based on the criteria as described in clause 4.3, the DSF the IMS for call routing. The DSF may as an option 
work in collaboration with the HSS. 

NOTE 1 : Steps 4 and 5 may consist of a sequence of messages for communication to/from different VCC 
Functional Elements. 

NOTE 2: The invocation order of VCC Functional Elements is implementation specific. 

6. Multiple options are possible, two of which are shown: 

6a. The DSF sends the INVITE containing the unmodified R-URI toward the S-CSCF. 
6b. The DTE sends the INVITE containing the unmodified R-URI toward the S-CSCF. 

7. The S-CSCF forwards the INVITE toward the UE in the IMS domain. 
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6.4 



Domain transfer 



6.4.1 Domain transfer procedures 



6.4.1.1 



General 



Domain Transfer procedures enable voice continuity between CS domain and IMS while maintaining an active voice 
session when using a VCC UE. All Domain Transfer procedures associated with a VCC subscriber call including initial 
and subsequent transfers are executed and controlled in the user's home IMS network by the DTP upon UE's request. 

VDN and VDI are used during the execution of domain transfers. The VDN and VDI are stored in the UE. The VDN 
and VDI are configured into the UE during initial provisioning. 



6.4.1.2 



Enablement of domain transfer procedures 



Static anchoring techniques are employed to establish a Spec (3rd party call control) function for VCC subscriber voice 
calls using a VCC UE at the DTE upon session establishment. The DTE is invoked as part of originating or terminating 
iEC execution at the VCC subscriber's S-CSCE or invoked by addressing its PSI from the IMRN. The DTE inserts itself 
in the signalling path of the VCC subscriber's voice calls made using VCC UE by employing a Routing Spec function. 
Eor an originating voice session, the DTE terminates an Access Leg from the user and establishes a Remote Leg toward 
the remote end; for a terminating voice session, the DTE terminates a Remote Leg from the remote end and establishes 
an Access Leg toward the user. The DTE subsequently coordinates the call control signalling exchange between the 
Access Leg and the Remote Leg associated with a VCC subscriber voice call. 

Eigure 6.4.1.2-1 shows Spec at the DTE when the Access Leg is established via the CS domain and IMS respectively to 
illustrate its use for precondition of Domain Transfer procedures. The figure is for illustration of the Spec at the DTE 
and its use for Domain Transfer procedures, hence it only shows the signalling and bearer components relevant to the 
enablement and execution of Domain Transfers; for example, the CSAE which may be involved in anchoring of CS 
originating calls in IMS or the P-CSCE involved in establishing IMS session are not shown. 
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Figure 6.4.1 .2-1 : Spec at DTF 
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The other AppHcation Servers associated with the call are linked in as part of the Remote Leg of the call. These 
Application Servers will not be impacted by Domain Transfer procedures executed on the Access Leg. 

NOTE: Any SIP ASs linked in before in the Access Leg between the DTP and UE will be removed from the 
signalling path upon the Domain Transfer. 



6.4.1.3 



Execution of domain transfer procedures 



Upon detection of conditions requiring Domain Transfer, the UE establishes an Access Leg with the DTE via the 
transferred-in domain to request Domain Transfer to the transferred-in domain. The DTE executes the Domain Transfer 
procedure by replacing the Access Leg currently communicating to the Remote Leg with the Access Leg established via 
the transferred-in domain. The Access Leg established via the transferred-out domain is subsequently released. When 
the switch of the Access leg from the transferred-out domain to the transferred-in domain is executed, the Remote Leg 
is also updated in order to forward the U-Plane data to the transferred-in domain. 

The execution of the Domain Transfer procedure consists of the following basic steps: 

1. The UE establishes an Access Leg via the transferred-in domain after registering (per clause 6.1 or clause 6.2) 
with the transferred-in domain as needed. 

2. The DTE performs the Access Leg Update to switch the Access Leg communicating with the Remote Leg from 
transferred-out domain to transferred-in domain. If the remote party is IMS capable, the U-plane path is switched 
end-to-end (i.e. between UEs). And if the remote party is CS/PSTN, U-plane path is switched between VCC UE 
and MGW. It means MGW becomes the U-plane anchor point, even if both sides are in CS domain. The U-plane 
path after the domain transfer represents figure 6.4. 1.3- land figure 6.4.1.3-2. Eor Access Leg Update procedures, 
refer to clause 6.4.1.4 Access Leg Update toward the remote end. The VCC UE switches the voice traffic from 
the transferred-out domain to the transferred-in domain as soon as the Access Leg in the transferred-in domain is 
fully established. 

3. Both the VCC UE and the DTE release the source Access Leg, which is the Access Leg previously established 
via the transferred-out domain. Eor Source Access Leg Release procedures, refer to clause 6.4.1.5 Source Access 
Leg Release. 
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Figure 6.4.1.3-1: U-plane path between VCC UE and IMS UE 



ETSI 



3GPP TS 23.206 version 7.2.0 Release 7 



23 



ETSI TS 123 206 V7.2.0 (2007-03) 



Switch at MGW 



CS Radio 




,-^VfGGf#-1- 



M0VW1 



CS Leg 



VCC 
UE#A 




CS UE#B 



Control Plane 
User Plane 



IMS+IP Leg 

NOTE: MGW#1 and MGW#2 may be merged. 

Figure 6.4.1.3-2: U-plane path between VCC UE and CS UE / PSTN 



6.4.1.4 



Access Leg Update toward the remote end 



upon receiving a request for execution of Domain Transfer, the DTF performs the Access Leg Update by switching the 
Access Leg communicating with the Remote Leg from transferring-out domain to transferring-in domain. 



1 . UPDATE or Re-INVITE 



2. UPDATE or Re-INVITE 



Figure 6.4.1.4-1 : Access Leg Update toward the remote end 

The remote end in figure 6.4.1.4-1 represents a UE supporting terminations per TS 23.228 [2] (i.e. including NI-T). 
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1-2. The DTF updates the Access Leg by communicating the SDP of the Access Leg established in the 

transferring-in domain to the remote end via the user's S-CSCF. Access Leg update happens according to SIP 
session modification procedures (see RFC 3261 [18]). 

The remote end in figure 6.4.1.4-2 represents an MGCF for CS/PSTN Remote Party. 
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Figure 6.4.1.4-2: Access Leg Update toward the remote end 

1-2. These steps are the same procedures described in figure 6.4.1.4-1. 

3. MGCF instructs MGW to update a termination towards the access leg of the transferred in domain to the context, 
and to release the termination for the access leg of the transferred out domain from the context. 



6.4.1.5 



Source Access Leg Release 



When the session modification procedures complete, the Source Access Leg Release is executed by initiating a session 
release. This is done for the Access Leg previously established via the transferring-out domain using the AS/UE session 
release procedures per TS 23.228 [2]. The VCC UE and the DTF shall initiate the Session Release procedure when the 
switch to the transf erred-in domain is complete. 

6.4.2 Domain transfer information flows 



6.4.2.1 



Domain transfer: IMS to CS domain 



Figure 6.4.2.1-1 Domain Transfer - IMS to CS domain, provides an information flow for Domain Transfer of voice 
calls made using VCC UE in IMS to CS domain direction. The flow is based on the precondition that the user is active 
in an IMS voice originating or terminating session at the time of initiation of Domain Transfer to CS. 
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Figure 6.4.2.1-1 : Domain transfer - IMS to CS domain 

1 . If the user is not attached to the CS domain at the time when the UE determines a need for Domain Transfer to 
CS, the UE performs a CS Attach as specified in clause 6.1. It subsequently originates a voice call in the CS 
domain according to "Information flow for an MO call" in TS 23.018 [3] using the VDN to establish an Access 
Leg via the CS domain and request Domain Transfer of the active IMS session to CS Domain. 

2. The originating call is processed in the CS network according to CS origination procedures described in 
clause 6.2.2 VCC UE Origination from CS Domain for routing to IMS. The DTF (PSI) DN is resolved using the 
VDN at the CS network. 

3. The VMSC routes the call towards the user's home IMS network via an MGCF in the home network. 

4. The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating VCC user. 

5. The I-CSCF routes the INVITE to the DTF in VCC Application based on one of the following standard 
procedures specified in "PSI based Application Server termination - direct and PSI based Application Server 
termination - indirect" procedures in TS 23.228 [2]. 

NOTE 1 : Direct routing to the DTF AS is shown, although routing via S-CSCF is also possible. 

NOTE 2: Routing to the DTF may also be performed via the CSAF to allow the originating call from the CS 
network to be delivered to the CSAF before being routed to the DTF. 

6. The DTF completes the establishment of the Access Leg via the CS domain. The DTF performs the Domain 
Transfer by updating the Remote Leg with the connection information of the newly established Access Leg 
using the Access Leg Update procedure as specified in clause 6.4.1.3. 

7. The source Access Leg (which is the Access Leg previously established over IMS) is released as specified in 
clause 6.4.1.4. 

NOTE 3: Steps 6 and 7 consist of a sequence of messages, some of which may occur in parallel. 
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6.4.2.2 



Domain transfer: CS domain to IMS 



Figure 6.4.2.2-1 Domain Transfer - CS domain to IMS, provides an information flow for Domain Transfer of voice 
calls made using VCC UE in the CS domain to IMS direction. The flow is based on the precondition that the user is 
active in a CS voice originating or terminating session at the time of initiation of Domain Transfer to IMS. 



Home IMS Network 



UE-CS 



UE-IMS 



S-CSCF 



DTF 



1. INVITE (VDI) 



P INVITF (Vni) 



3. Access Leg Update 



4. Source Access Leg 
Release 



Figure 6.4.2.2-1 : Domain transfer - CS domain to IMS 

1 . When the UE determines a need for domain transfer, the UE initiates registration with IMS (if not already 
registered in IMS) as specified in clause 6.1. It subsequently initiates an IMS originated session toward the DTF 
in VCC Application using a VDI to establish an Access Leg via IMS and request Domain Transfer of the active 
CS session to IMS. Please refer to clause 6.2.3 for details on IMS origination procedure. 

2. The IMS session is processed at the S-CSCF and delivered to the DTF as specified in clause 6.2.3 VCC UE 
Origination from IMS. 

3. The DTF completes the establishment of the Access Leg via IMS. The DTF performs the Domain Transfer by 
updating the Remote Leg with connection information of the newly established Access Leg (see the Access Leg 
Update procedure, clause 6.4. L3). 

4. The source Access Leg which is the Access leg previously established over CS is subsequently released (see 
clause 6.4. L4). 

NOTE: Steps 3 and 4 consist of a sequence of messages, some of which may occur in parallel. 



6.4.2.3 



Subsequent domain transfers 



Procedures for subsequent Domain Transfers to CS domain and IMS of voice calls made using VCC UE are the same as 
procedures for initial Domain Transfers specified in clause 6.4.2.1 for IMS to CS domain and clause 6.4.2.2 for CS 
domain to IMS. 

6.4.3 Void 
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6.5 Supplementary services 

6.5.1 General 

This clause addresses the services impacted by VCC. The CS service set used for this clause is referenced in 
TS 22.004 [8]; whereas the IMS service set is referenced in TS 22.173 [9]. 

This clause specifies service behaviours for calls which are anchored in IMS. 

The following requirements shall be taken into account for supplementary service handling in VCC: 

- The impact of domain selection and domain transfer shall be avoided or minimized; 

- The unnecessary degradation of voice call quality shall be avoided or minimized; 

- The service consistency between CS domain and IMS shall be considered. 

6.5.2 Supplementary services behaviour 

6.5.2.1 General 

Voice calls for VCC subscribers established via the CS domain may or may not be anchored in the IMS, subject to 
operator policy. Supplementary services for VCC subscriber CS calls which are not anchored in IMS are provided as in 
TS 23.011 [12] andTS 24.010 [14]. 

6.5.2.2 Line Identification supplementary services 

6.5.2.2.1 General 

There is no impact on the Line Identification Supplementary Services during Domain Transfer, because these services 
occurred before the call is set up or delivered. 

6.5.2.2.2 IMS: Originating Identification Presentation (OIP), OS: Galling Line Identity 
Presentation (CLIP) 

There is no impact on the CLIP or OIP services. 

6.5.2.2.3 IMS: Terminating Identification Presentation (TIP), CS: Connected Line Identity 
Presentation (COLP) 

There is no impact on the COLP or TIP services. 

6.5.2.2.4 IMS: Originating Identification Restriction (OIR), CS: Calling Line Identity 
Restriction (CLIR) 

There is no impact on the CLIR or OIR services. 

6.5.2.2.5 IMS: Terminating Identification Restriction (TIR), CS: Connected Line Identity 
Restriction (COLR) 

There is no impact on the COLR or TIR services. 

6.5.2.3 IMS: Gonnnnunication Diversion (GDIV), GS: Gall Forwarding supplementary 
services 

Call Forwarding Supplementary Services may be provided in IMS. 

It is unnecessary to reroute a CS incoming call to IMS for anchoring in IMS if the call is redirected to some other party 
(the call will never reach the intended VCC UE, and therefore the VCC UE cannot request a domain transfer). A 
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rerouting to IMS would result in multiple transcoding, network resource usage, and would prevent optimal routing. This 
can be prevented by invoking the pending call forwarding supplementary service instead of obtaining the IMRN when 
Call Forwarding Supplementary services are provided in the CS domain. 

NOTE: Since there are multiple implementation options for call diversion from the CS domain to the IMS listed 
in Annex A, it also depends on the chosen call diversion option whether the pending call forwarding 
supplementary service can be invoked instead of obtaining the IMRN. 

6.5.2.4 IMS: Communication Hold, CS: Call Wait and CS: Call Hold supplementary 
services 

There is no impact on the Communication Hold/Call Wait and Call Hold Supplementary Services when remaining in a 
particular domain. It is not possible to maintain these services between domains if Domain Transfer occurs. 

6.5.2.5 IMS: Conference (CONF), CS: Multiparty (MPTY) supplementary service 

There is no impact on the Conference or multiparty service when remaining in a particular domain. It is not possible to 
maintain these services between domains if Domain Transfer occurs. 

6.5.2.6 IMS: Call Barring (CB), CS: Call Barring (Operator Determined and 
supplementary service) 

Call Barring Supplementary Services and Operator Determined Barring may be provided in IMS. 

NOTE: In this case a call originated in CS that is not anchored in IMS will not be subject to call barring if call 
barring services are not provided in CS. 

In accordance with existing procedures, if the VCC subscriber has Barring of all Outgoing Calls (BaOC) active in the 
CS domain, BAoC is invoked before CAMEL triggers are executed.. This will result in a CS originated call not being 
established. This procedure also applies to the UE's attempt to perform a Domain Transfer from IMS to the CS domain 
if the VCC subscriber has BAoC service active in the CS domain. 

In accordance with existing procedures, if the VCC subscriber has International outgoing call barring (BoIC) active in 
the CS domain, then BoIC is invoked on the IMRN or DTE PSI DN. As a result the anchoring of calls established in the 
CS domain and Domain Transfers of calls established in IMS are both impacted if the IMRN or DTE PSI DN is 
considered by the VMSC to be an international number. Eurther, a barred call may be permitted if the IMRN is 
considered by the VMSC to be a local number. 



6.5.3 Impact of service behaviour 



A VCC UE shall not request a Domain Transfer when it is engaged in an active CONE or MPTY service that it is in 
control, because the behaviour is not defined after a Domain Transfer has occurred (see clause 6.5.2.5). 

A VCC UE engaged in an active call/session and a held/waiting call/session on the transferring-out domain may request 
domain transfer according to operator policies (see clause 6.8.1). In the case that domain transfer is allowed to be 
performed, the VCC UE shall initiate the release of the held/waiting call/session before initiating a domain transfer 
request for the active call/session; the VCC UE may request domain transfer for the active call/session even if the VCC 
UE fails in releasing the held/waiting call/ session (e.g. in case of loss of coverage in the transferring-out domain). 
When the DTE receives a request for domain transfer from the transferring-in domain, if it finds multiple calls/sessions 
in the transferring-out domain and if it is able to identify the active call/session, it shall transfer, if permitted by the 
operator policy, the active call/session to the transferring-in domain and it shall release the held/waiting call/session in 
the transferring-out domain. Otherwise the DTE shall reject the request for domain transfer. 

The static and dynamic service data maintained in CS domain and IMS could result in an inconsistent user experience. 

Editor's Note: It is EES if the Spec is able to reissue the invite for a waiting call automatically upon transfer of the 
active leg. 
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6.6 CAMEL services 

It is unnecessary to reroute a CS incoming call to IMS for anchoring in IMS if the call is redirected to some other party 
(the call will never reach the intended VCC UE, and therefore the VCC UE cannot request a domain transfer). A 
rerouting to IMS would result in multiple transcoding, network resource usage, and would prevent optimal routing. This 
can be prevented by invoking CAMEL redirection services instead of obtaining the IMRN when CAMEL redirection 
services are provided in the CS domain. 

NOTE: The use of CAMEL for rerouting from CS to IMS (for anchoring) could cause impacts to service 
behaviours when using CAMEL services in the CS domain. To avoid these impacts, the gsmSCF 
(providing the CS rerouting function) may have to manage the interactions of the CS rerouting function 
with other services, or the service could be disabled in CS and be provided in IMS. 

6.7 Presence services 

Presence services are provided by the respective bearer networks, and are not impacted by this feature. 

6.8 Other procedures 

6.8.1 User preferences and operator policy 

User preferences shall be taken into account by the domain selection function when deciding over which domain an 
incoming voice call shall be routed to the VCC UE. User preferences may be transmitted over the V3 reference point, 
and indicate which domain is preferred for routing terminating calls when the VCC UE is registered on both accesses. 

Operator policy is provisioned in the network by the operator, and should be communicated to the VCC UE during 
initial provisioning or via OMA Device Management [19]. Operator policy should be communicated to the VCC UE, 
via OMA Device Management, whenever the policy is updated by the operator. It shall indicate which network is 
preferred for originating calls performed by the VCC UE, and whether domain transfer is restricted to a single direction 
(i.e. IMS to CS or CS to IMS). The UE shall take this information in account when deciding which access to use for 
outgoing calls or before considering initiating domain transfer. 



7 Security 

7.1 General 

There are no impacts on existing security mechanisms for the CS Domain or for IMS as a result of Domain Transfers. 

7.2 Access security for CS Domain 

TS 33.102 [5] describes the Security Architecture for GSM and UMTS subscribers, VCC places no additional 
requirements upon the CS domain above those described in TS 33.102 [5]. 



7.3 Access security for IMS 



TS 33.203 [6] specifies the security features and mechanisms for secure access to the IM subsystem (IMS). VCC places 
no additional requirements upon the IMS above those described in TS 33.203 [6]. 
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8 Charging 

8.1 General description 

The charging strategy applied in VCC shall ensure the completeness and correctness of charging during Domain 
Transfer procedures, and avoid possible double billing in IMS and CS, which may be introduced by the anchoring in 
IMS of CS originating and terminating voice calls. 

Meanwhile, the accounting strategy applied in VCC shall provide enough information for the settlement between 
different operators, including the settlement between the providers of CS domain and IMS, and the settlement between 
the providers of IPCAN and IMS Core. 

8.2 Ciiarging strategy 

To ensure the completeness and correctness of charging during Domain Transfer procedure, and avoid possible double 
billing in IMS and CS, the following strategy may be applied: 

1 . Provide cohesive charging records with a complete call continuity history for the whole duration of a VCC 
subscriber voice session by the DTF. 

2. For cases of CS origination and CS termination, correlate the charging records generated in CS and IMS for the 
single CS origination/termination, to avoid double billing to the subscriber. 

3. Treat the charging records generated in the transferring-in domain for the call/session established during the 
domain transfer as subsequent Access Legs, and therefore do not impact the direction of the initial call/session 
for the purpose of charging. 

4. Keep the start of charging in the transferring-in domain align with the stop of charging in the transf erring-out 
domain, to avoid double billing to the subscriber in these periods of time. 

For VCC online charging, the following strategies shall be ensured: 

1 . Completeness and correctness of charging; 

2. Avoid possible double billing in IMS and CS domains. 

To avoid online charging correlation in IMS and CS domain, the VCC online charging should be performed only in 
IMS, i.e. prepaid service logic in CS domain should not be invoked for anchored CS origination/termination call and 
subsequent CS origination call established for performing domain transfer. 

NOTE: If a CS call is not anchored standard CS service is applied e.g. pre-paid. 

Besides that, the DTF should report information related to the initial call establishment as well as the information 
related to the domain transfer procedure to OCS for correct credit control purpose. 

8.3 Accounting strategy 

To assist in performing the settlement between operators, the following strategy shall be applied: 

1 . Provide cohesive charging records with a complete call continuity history for the whole duration of a VCC 
subscriber voice session by the DTF. 

2. Use the charging records for subsequent Access Legs generated in CS/IMS domain and the charging records 
generated in MGCF performing CS-IMS interworking, taking the complete call continuity history described 
above as reference, to perform the settlement between the providers of CS domain and IMS. 

3. Use the access network information in IMS charging records, taking the complete call continuity history 
described above as reference, to perform the settlement between the providers of IPCAN and IMS Core. 
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Annex A (informative): 

Call diversion techniques from CS to IMS 

An incoming call for a subscriber with a service provided by the IMS (e.g. a VCC subscriber) may be routed either 
through the CS domain or IMS network. For a VCC subscriber using a VCC enabled terminal, voice, calls that are 
routed to the CS domain must be anchored at the DTF in the IMS network prior to the routing of the call to the 
subscriber. 

NOTE: Requirements and preconditions for anchoring of CS calls for VCC subscriber in IMS are documented in 
clause 6.3 of the present document. 

A.1 Implementation options for call diversion from CS to 
the DTF in IMS 

Several techniques available in the current CS networks may be used to implement the call diversion from CS to IMS, 
as itemized below: 

1 Use of CAMEL for call diversion to IMS 

This option applies to configurations requiring handling of incoming calls at the GMSC function. Upon receipt 
of an incoming voice call, the GMSC queries the HSS for routing information via Send Routing Information 
(SRI) query. The user profile in the HSS is configured to return T-CSI including a gsmSCF address to the 
GMSC in response to the SRI query. When handling voice calls for a VCC subscriber, the subsequent processing 
at the gsmSCF and the GMSC results in routing of the call to the IMS using the IMRN. The call is routed to the 
DTF according to standard IMS routing procedures. In order to determine the necessary information to complete 
the call, the VCC Application uses the IMRN or the ISUP information mapped to SIP headers. 

2 HSS directed call diversion to IMS 

This option also applies to configurations requiring handling of incoming calls at the GMSC function. Upon 
receipt of an incoming voice call, the GMSC queries the HSS for routing information via Send Routing 
Information (SRI) query. Based on non- standardized mechanism, the user profile in the HSS is configured to 
return an IP Multimedia Routing Number (IMRN) to the GMSC in response to the SRI query, when the call is 
directed to a VCC subscriber using a VCC UE. The subsequent processing at the GMSC results in routing of the 
call to IMS using the IMRN. Two methods may be used to ensure correlation between the IMRN and the 
original called party. 

a. Cooperative allocation/deallocation: In this method, the IMS is made aware of the assigned IMRN and 
when a call is received for that number, the original number is retrieved. This method is similar to a VMSC 
managing roaming numbers. 

b. Algorithmic: In this method, a known algorithm is used to derive the IMRN at the CS, and to deduce the 
original called number from the IMRN at the IMS. One method of performing such an algorithm could be 
e.g. use of a prefix. In such a case, care is required in the network configuration to avoid looping for the case 
when the call is subsequently routed from the IMS to the CS domain for call termination. 

3 Static diversion from GMSC with dedicated trunk groups 

This option also applies to configurations requiring handling of incoming calls at the GMSC function. Dedicated 
trunk groups may be used at the GMSC to divert CS terminations to the MGCF. 

NOTE 1 : The handling of calls other than voice calls needs to be taken in account if this solution is chosen. 

4 Static diversion using LNP 

This option may be used for routing of calls originating in PSTN networks to IMS. A local number portability 
database dip may be used to reroute VCC subscriber calls to the MGCF. 

NOTE 2: The handling of calls other than voice calls needs to be taken in account if this solution is chosen. 
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5 Direct routing to IMS 

Translations may be set up in the PSTN network to route the mobile subscriber calls to the MGCF when the call 
is received. This way the standard IMS routing technique in TS 23.228 [2] can be used. 

NOTE 3: The handling of calls other than voice calls needs to be taken in account if this solution is chosen. 

NOTE 4: With some of the aforementioned options, care must be taken to avoid a circular loop which may result 
when used in conjunction with certain techniques applied to route the call from IMS to the terminating 
user via CS network. Techniques for the prevention of circular looping are described in Annex C. 
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Annex B (informative): 
Domain selection for VCC 



Clause 4.3 describes the factors which should be considered when the domain selection is executed in VCC, but since 
the actual domain selection handling logic is outside the scope of the standardization, there are several ways to 
implement the handling logic of the domain selection function (DSF) in the VCC Application with one or more factors 
taken into account, e.g., route the call to IMS directly, route the call to CS directly, route the call to the last used 
domain, route the call to the domain the existing call used and so on. 

If all factors described in the clause 4.3 are considered for domain selection decision, the following figure illustrates a 
possible handling logic of the DSF. 




Route the call to the CS 
domain 



Deliver the call to IMS 

registered UE/ trigger the IMS 

un-registered service 



Figure B-1. Domain Selection Function (DSF) handling logic 
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Annex C (informative): 

Techniques for the prevention of circular looping for CS 

Terminations 

When an incoming CS call is anchored at the VCC application using certain implementation options described in Annex 
A.l, then as a result of domain selection, the call may be routed back to the CS domain to determine the CSRN for CS 
termination. In this case, the call may be treated as a new incoming call from the CS network, and then be re-routed to 
the IMS for anchoring again, thus creating a circular loop. 

C.1 Implementation options prevention of circular looping 
for CS Terminations 

Several implementation techniques may be used to avoid circular looping, as itemized below: 

1 Use of VCC Application for deriving the MSRN 

When the domain selection function decides that the call shall be terminated in the CS domain, the VCC 
application retrieves the MSRN from the VMSC via the HSS using one of the following methods: 

a. MAP SRI Query: This option makes use of a MAP Interface between the VCC Application and the HSS to 

request allocation of an MSRN from the HSS for routing of the call to the VMSC currently serving the 
subscriber. 

b. Sh UDR Query: This option makes use of the Sh interface between the VCC Application and the HSS. The 
VCC Applications sends a Sh UDR query to the HSS to request allocation of an MSRN for routing of call to 
the VMSC currently serving the subscriber. 

2 Use of a specific CSRN to indicate the anchored call 

When the domain selection function decides that the call shall be terminated in the CS domain, the VCC 
application allocates a specific CSRN. The specific CSRN can be a MSISDN with added prefix digits. The VCC 
Application uses the specific CSRN to route the call to the CS network. The following options are available to 
resolve the MSISDN of original called party from the CSRN. 

a. MGCF resolution: In this option, the VCC AppHcation forwards the call to the MGCF (which has a GMSC 
function). The specific CSRN is used by the MGCF to recognise that the VCC application has already 
anchored the call in IMS, and that the call shall be terminated in the CS domain. The MGCF resolves the 
MSISDN from the CSRN and invokes GMSC functionality integrated in the MGCF for handling the CS 
terminating side process. In particular, the MGCF/GMSC includes the "suppress-TCSI" parameter in the 
MAP SRI sent to the HSS. 

b. GMSC resolution: In this option, the VCC Application forwards the call to the MGCF which forwards the 
call to GSMC. The specific CSRN is used by the GSMC to recognise that the VCC application has already 
anchored the call in IMS, and that the call shall be terminated in the CS domain. The GMSC resolves the 
MSISDN from the CSRN and invokes the CS terminating side process. In particular, the GMSC includes the 
"suppress-TCSI" parameter in the MAP SRI sent to the HSS. 

c HSS resolution: In this option, the VCC Application forwards the call to the GMSC . The GMSC treats the 
call as a normal terminating call and sends a MAP SRI request to the HSS for the specific CSRN, The 
specific CSRN is used by the HSS to recognise that the VCC application has already anchored the call in 
IMS, and that the call shall be terminated in the CS domain. The HSS resolves the MSISDN from the CSRN 
and uses standard call terminating procedures to obtain routing information from the VMSC. 

3 Use of a dynamically allocated CSRN to route via the GMSC 

This option uses a dynamically allocated CSRN to divert the call to the appropriate GMSC as described below: 
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- The VCC Application allocates a CSRN which maps to an appropriate GMSC. Standard CS termination 
procedures are executed at the GMSC. 

- The GMSC is configured with N-CSI and criteria corresponding to the CSRN. This causes the GMSC to 
issue an initial DP containing the CSRN to the gsmSCF. 

- The gsmSCF performs a function on the CSRN to obtain the MSISDN of the called party number and the 
MSISDN is returned to the GMSC in a CONNECT operation together with the CSRN as a Re-direction Id. 

- The GMSC continues the normal CS terminating process by issuing an SRI to the HSS using the MSISDN, 
which causes T-CSI to be returned back to the GMSC. 

- The GMSC issues another initial DP containing both MSISDN and CSRN to the gsmSCF. The gsmSCF 
recognises that it has been triggered for the second time (due to the presence of the CSRN) and therefore 
returns a CONTINUE for the MSISDN, thus avoiding a circular loop. 

- The GMSC sends a MAP SRI query to the HSS with the "suppress-TCSI" parameter, thus allowing the HSS 
to obtain the MSRN through standard call terminating procedures. 
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